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APPUCATION PROGRAMMING INTERFACE FOR ADMINISTERING THE 
DISTRIBUTION OF SOFTWARE UPDATES IN AN UPDATE DISTRIBUTION 

SYSTEM 

FIELD OF THE EnJVENTION 
The present invention relates to software and computer networks, and, in 
particular, the present invention relates to an application programming interface for 
administering the distributing of software updates in an update distribution system. 

BACKGROUND OF THE INVENTION 

Nearly all commercially available software products undergo a continual revision 
process to repair or update features of the software. Each revision of a software product 
frequently requires adding new files, replacing existing files with newer revisions, 
deleting obsolete files, or various combinations of these actions. This process of 
replacing older files, adding new files, and deleting obsolete files of a software product 
will be referred to hereafter as "updating the product," and the data collection, including 
binary files, data files, update instructions, metadata, database data, system registry 
settings, security settings, and the like, used in updating the product will be referred to 
hereafter more simply as an "update." 

Once a software provider has created an update for a software product, either to 
fix a problem, enhance security, or add new features, the software provider will want to 
make that update widely available to its customer base. Quite often, such as when the 
update is directed at correcting a flaw in the product or addressing a critical security 
issue, the software provider will want that update installed on the customers' computers as 
soon as possible. Indeed, most software providers have a business incentive to distribute 
software updates to their customers as quickly and as trouble-fi-ee as possible. 

The computer industry has experienced an explosive growth in the number of 
computers coimected to networks, and in particular, to the Intemet. Due to this explosive 
growth, and due to the communication abilities available through a connection to the 
Intemet, the Intemet has become an important and integral channel for software providers 
to distribute updates to their customers. In fact, the Intemet has become the primary 
distribution channel for many software providers to provide software updates to their 
customers. It is often in the best interest of software providers to distribute software 
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Updates over the Memet, as electronic update distribution over the Intemet reduces their 
overall costs and enables customers to obtain the software updates as soon as they are 
available. More and more frequently, these software updates are conducted automatically 
over the Intemet, without any user intervention. 
5 While the Intemet is now commonly used as a conduit for distributing software 

updates from software providers, several issues frequently arise. Two such issues include 

(1) efficiency relating to the update distribution infrastmcture/resources, and 

(2) administrative control over the distribution and installation of sofl^vare updates. 

In regard to efficiency of the distribution resources, networks, including the 

10 Intemet, possess only a finite amount of communication resources, often referred to as 
bandwidth. A finite amount of communication bandwidth frequently results in 
bottlenecks, especially in regard to software updates for popular software products, such 
as Microsoft Corporation's Windows® family of operating systems and related 
productivity products. Such bottlenecks exist even when software updates are made 

15 available on multiple download locations distributed throughout the Intemet. One reason 
that such bottlenecks occur is the unstmctured access model made available by the 
Intemet. For example, if a first user at computer A requests the latest download of a 
software product, the download passes through the first user's independent service 
provider (ISP). Furthermore, the request is treated as a single, individualized access, 

20 meaning that the request is treated independent of, and unrelated to, any other network 
traffic and/or request. As such, if a second user at computer B, who also happens to have 
the same ISP, requests the same download as the first user, the request from the second 
user is also treated as a single, individualized access. In this example, the same download 
will be transmitted over the same infrastructure twice, because each request was treated in 

25 isolation. Clearly, if the nxxmber of users mcreases substantially, the finite 
communication bandwidth will become a bottleneck. In this example, which is quite 
common, it would have been much more efficient if the download could have been 
cached at a local location, and each user request satisfied from the local cache. 

With regard to control of distribution, many organizations, especially large 

30 organizations, have legitimate reasons to control the distribution of updates to their 
computers. For example, unfortunately some updates have or introduce flaws, frequently 
referred to as bugs, that "break" features of a software product. These broken features 
may be insignificant, but all too often they can dismpt a business's mission-critical 
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features. As a business cannot afford to lose its mission-critical features, a responsible 
business will first evaluate and test each software update within a controlled environment 
for some period of time prior to releasing the update to the remamder of their computers. 
This evaluation period permits the organization to validate whether an update will 
5 adversely affect a mission-critical feature. Only after it has been satisfactorily 
detemiined that an update will not bring down any mission critical feature is the update 
permitted to be distributed to the remainder of the organization's computers. Clearly, 
most organizations must exercise control over the installation of software updates on their 
computers. 

10 Another reason that a business or an organization often needs to control 

distribution of software updates is to ensiu-e consistency among the computes in the 
organization. It is very important for information service departments to have a 
standardized, target platform upon which all computers operate, whether it is for a word 
processor or an operating system. Without a standard, software and computer 

1 5 maintenance may be uimecessarily complex and difficult. 

Still another reason that local control is important is for billing purposes. In large 
organizations, it is often inefficient to individually install software on a computer, or to 
individually maintain licenses for a particular software product for each computer in the 
organization. Instead, a single site license permits an organization to run a software 

20 product on numerous computers. Thus, an organization may be required to report the 
number of computers running a product imder the site license, or may need to Umit the 
number of computers rumiing a product under a site license. All of these reasons often 
require local control over software update distribution. 

In light of the various above-identified issues relating to software update 

25 distribution, what is needed is an extensible software update distribution architecture for 
providing control over the distribution of software updates, as well as increasing their 
distribution efficiency. The present invention addresses these and other issues found in 
the prior art. 

30 SUMMARY OF THE INVENTION 

According to aspects of the present invention, an update service node having an 
application programming interface for administering the distribution of software updates 
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on the update service node, is presented. The update service node includes an update 
store for storing software updates. The update service node also includes an update web 
service through which the update service node obtains software updates from a parent 
update service node over a communication network, and through which the update 
5 service node distributes software updates to child update service nodes over the 
communication network. Still further, the update service node includes an administration 
application programming interface (API) through which an administrator estabHshes 
controls the distribution of software updates to child update service nodes and client 
computers, wherein the administration API is an object exposing a plurality of interface 

10 calls through which the administrator establishes said rules. 

According to additional aspects of the present invention, an application 
programming interface (API) for administering the distribution of software updates on an 
update ser\dce node, is presented. The API comprises a get configuration interface call 
which returns a configuration interface object for reading and writing software update 

15 administration configuration values to the update service node. The API further 
comprises a get subscription interface call wliich returns a subscription interface object 
defined on the update service node. The API still further comprises a get update interface 
call which returns a update interface object corresponding to an update identifier passed 
in the get update interface call, as well as a get updates interface call which returns an 

20 update collection object containing update interface objects corresponding to values 
passed in the get updates interface call. The API also comprises a get computer interface 
call which returns an client computer object corresponding to the a client computer 
associated with the update service node and that was identified in the get computer 
interface call, and a get computers interface call which returns a computer collection 

25 object including chent computer objects corresponding to client computers associated 
with the update service node. Additionally, the API comprises a get group interface call 
which returns an target group object that was identified in the get group interface call, and 
a get groups interface call which returns a target group collection object including target 
group objects corresponding to target groups on the update service node. 

30 According to still further aspects of the present invention, a software update 

distribution system for distributing software updates, is presented. The software update 
distribution system comprises an update service node and an administration application 
programming interface (API) associated with the update service node. The 
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administration API is an interface object exposing a plurality of interface calls for 
controlling the distribution of software updates. The administration API includes a get 
configuration interface call which returns a configuration interface object for reading and 
writing software update administration configuration values to the update service node. 
5 The API fiirther includes a get subscription interface call which returns a subscription 
interface object defined on the update service node. The API still fijrther includes a get 
update interface call which returns a update interface object corresponding to an update 
identifier passed in the get update interface call, as well as a get updates mterface call 
which returns an update collection object containing update interface objects 

10 corresponding to values passed in the get updates interface call. The API also includes a 
get computer interface call which returns an client computer object corresponding to the a 
cUent computer associated with the update service node and that was identified iu the get 
computer interface call, and a get computers interface call which returns a computer 
collection object including chent computer objects corresponding to cUent computers 

15 associated with the update service node. Additionally, the API includes a get group 
interface call which returns an target group object that was identified in the get group 
interface call, and a get groups interface call which retums a target group collection 
object including target group objects corresponding to target groups on the \3pdate service 
node. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing aspects and many of the attendant advantages of this invention will 
become more readily appreciated as the same become better understood by reference to 
the following detailed description, when taken in conjunction with the accompanying 
drawings, wherein: 

25 FIGURE 1 is a pictorial diagram of an exemplary update distribution system 

formed in accordance with aspects of the present invention; 

FIGURE 2 is a block diagram illustrating exemplary logical components of an 
update service node formed in accordance with aspects of the present invention; 

FIGURE 3 is a block diagram illustrating exemplary logical components of a root 
30 update service node formed in accordance with aspects of the present invention; 

FIGURE 4 is a block diagram illustrating an exemplary exchange between a 
parent update service node and a child update service node in providing a software update 
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from the parent update service node to the child update service node in accordance with 
aspects of the present invention; 

FIGURE 5 is a flow diagram illustrating an exemplary routine executed on a child 
update service node to periodically obtain updates from its parent update service node; 
5 FIGURE 6 is a flow diagram of an exemplary subroutine suitable for use in the 

exemplary routine of FIGURE 5 for obtaining an update catalog from a parent update 
service node; 

FIGURE 7 is a flow diagram of an exemplary subroutine suitable for use in the 
exemplary routine of FIGURE 5 for obtaining a software update from a parent update 
10 service node; 

FIGURE 8 is a flow diagram of an exemplary routine for processing an update 
request from a child update service node; 

FIGURE 9 is a pictorial diagram for illustrating how the administration API is 
utilized with regard to configuring an update service node to distribute software updates 
15 to chent computers; and 

FIGURE 10 is a block diagram illustrating certain administration API calls for 
administering the distribution of software updates on an update service node. 

DETAILED DESCFOPTION OF THE PREFERRED EMBODIMENT 
According to aspects of the present invention, an update distribution system, 
20 organized in a hierarchical fashion, for distributing software updates is presented. 
FIGURE 1 is a pictorial diagram of an exemplary update distribution system 100 formed 
in accordance with aspects of the present invention. According to the present invention, 
at the "top" of an update distribution system, such as the illustrated update distribution 
system 100, is a root update service node 102. Software providers, such as software 
25 provider 110, distribute their software updates through the update distribution system 100 
by submitting the updates to the root update service node 102. According to aspects of 
the present invention, software providers, such as software provider 1 10, may submit 
their software updates to the root update service node 102 through a network, such as the 
Internet 108. 

30 A hierarchical update distribution system, such as the exemplary update 

distribution system 100, will likely include at least one other update service node in 
addition to the root update service node 102. As illustrated in FIGURE 1, the exemplary 
update distribution system 100 includes root update service node 102 and two additional 
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update service nodes: update service node 104 and update service node 106. According 
to the present invention, each hierarchical update distribution system is organized in a 
tree-like structure underneath the root update service node 102. In other words, each 
update service node in an update distribution system has zero or more child update 
5 service nodes. Thus, while the exemplary update distribution system 100 shows that each 
parent update service node, i.e., the root update service node 102 and update service 
node 104, have only one child, it is for illustration piuposes only, and should not be 
constmed as hmiting upon the present invention. Furthermore, with the exception of the 
root update service node 1 02, each update service node in an update distribution system 

10 has one parent update service node. Accordingly, as shown in FIGURE 1, update service 
node 104 is a child node to the root update service node 102, and update service node 106 
is a child node to update service node 104. As can be seen, each update service node, 
with the exception of the root update service node 102, can be both a child update service 
node and a parent update service node. 

15 As illustrated in the exemplary update distribution system 100, the root update 

service node 102 communicates with update service node 104 through the Intemet 108. 
However, it should be xmderstood that this is illustrative only, and should not be 
construed as limiting upon the present invention. Each update service node in an update 
distribution system need only be able to communicate with its parent and/or children 

20 through some commiinication network. Thus, while update service node 104 
communicates with its parent, root update service node 102, through the Intemet 108, it 
may alternatively communicate with its child update service nodes, such as update 
service node 106, via a local area network 124. 

Also shown in FIGURE 1, update service node 106 resides within a 

25 sub-netsvork 126 of the local area network 124. As an example, local area network 124 
may correspond to m organization's general corporate network, and update service 
node 104 represents the corporation's link to the update distribution system 100, via its 
comiection to its parent, root update service node 102. Further, sub-network 126 may 
correspond to an identifiable group of computers within the corporate network, such as a 

30 test/evaluation group, a remotely located office, or a mission critical group. As will be 
described in greater detail below, accordiug to aspects of the present invention, an 
administrator on update service node 104 is able to control the distribution of updates to 
update service node 1 06, and ultimately to client computers. 
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It should be appreciated that each update service node, including both the root 
update service node 102 and update service nodes 104 and 106, is configured to distribute 
software updates to both child update service nodes as well as client computers. As 
shown in FIGURE 1, the exemplary update distribution system 100 includes client 
5 computers 112-122. Each update service node, including the root update service 
node 102, distributes updates to child update service nodes and client computers 
according to local configuration information. According to one embodiment, an 
administrator defines groups and associates update distribution rules with those groups. 
Each update service node has at least one distribution group. 
10 As an example to illustrate how the update distribution system operates, assimie 

that local area network 124 corresponds to a business organization's corporate network. 
According to one embodiment of the present invention, an administrator, on update 
service node 104, may define multiple distribution groups for the corporate network 124, 
including an evaluation group, corresponding to the sub-network 126 including update 
15 service node 106 and chent computers 120 and 122, for evaluating the suitability of an 
update for the general corporate network 124, as well as a general corporate group 
including the update service node 104 and cUent computers 1 14-11 8. 

With regard to the evaluation group, the administrator includes the update service 
node 106 as a member, and associates rules with that group such that updates are 
20 immediately distributed to the evaluation group's members as they become available. 
Altematively, with regard to the general corporate group, the administrator adds client 
computers 114-118, and associates a rule such that updates are only distributed to the 
general corporate group members if specifically authorized by the administrator. Assume 
also that an administrator for child update service node 1 06 creates a default group 
25 consisting of the client computers 120 and 122 in the evaluation sub-network 126, to 
which any new software update may be inunediately distributed. 

Continuing the above example, a software provider 110 submits a software update 
to the root update service node 102. According to rules established at the root update 
service node 102, the update is eventually distributed to the corporate update service 
30 node 104. Upon receiving the update, per the rules established by the administrator, the 
corporate update service node 104 distributes the update to the members of the evaluation 
group (defined as only the child update service node 106), but withholds the update firom 
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the general corporate group pending specific authorization to distribute the update to that 
group. 

Continuing the above example, upon receiving the update, the evaluation update 
service node 106 processes the update with respect to each defined group. In this 
example, the evaluation update service node 106 has only one group. However, as 
previously mentioned, in an actual implementation, there may be multiple groups defined, 
each with a unique set of associated distribution rules. For this example, the evaluation 
update service node 106 immediately makes the update available for distribution to client 
computers 120 and 122. Client computers 120 and 122 may now be updated and the 
evaluation period/process may begin. 

Still continuing the above example, when the administrator on the corporate 
update service node 104 is sufficiently satisfied that the update is suitable for distribution 
over the entire corporate network 124, the administrator then explicitly authorizes the 
update to be distributed to the members of the general corporate group. The corporate 
update service node 104 correspondingly makes the update available to client 
computers 1 14-1 18. It should be understood that the evaluation update service node 106 
may also be included in the general corporate group. However, because the evaluation 
update service node 106 has already been updated, no additional update-related action is 
needed for distributing the update to the evaluation sub-network 126. 

As can be seen by the above example, the present invention offers significant 
benefits in terms of local distribution control and download efficiency. In addition to the 
above-described aspects of local distribution control, significant savings in 
communication bandwidth are also realized. For example, while the exemplary corporate 
network 124 illustrated in FIGURE 1 includes five cUent computers, the software 
provider's update was downloaded fi'om the root update service node 102 to the corporate 
update service node 104 only one time. Clearly then, as the number of client computers 
serviced by an update service node increases, the communication bandwidth usage 
between a parent update service node and a client update service node remains constant, 
thereby substantially reducing the amount of commimication bandwidth that would 
otherwise be used. Additionally, the update distribution system is both extensible and 
scalable. The update distribution system is extensible in at least two ways: any number of 
child update service nodes may be added to a parent update service node, and child 
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update service nodes may also be a parent update service node. Each sub-tree of the 
update distribution system may therefore be tailored to meet individual needs. 

FIGURE 2 is a block diagram iUustrating exemplary logical components of an 
update service node 200, such as the corporate update service node 104 (FIGURE 1) or 
5 the evaluation update service node 106 (FIGURE 1), formed in accordance with aspects 
of the present invention. As shown in FIGURE 2, an update service node 200 includes an 
update web service 202, a client update module 204, a child update module 206, and a 
reporting module 208. The exemplary update service node 200 also includes an 
authentication/ authorization module 210, an administration application programming 

10 interface (API) 212, an update content store 214, an administration user interface 218, 
and an update information store 216. 

The update web service 202 provides a common set of Web services through 
which cUent computers, child update service nodes, and a parent update service node can 
communicate with an update service node. For example, with reference to FIGURE 1 , in 

15 order for the child/evaluation update service node 106 to obtain a software update from 
the parent/corporate update service node 104, the client communicates through the 
parent's update web service 202. Similarly, when a parent update service node, such as 
root update service node 102, has information, including updates, to communicate to its 
child update service node 104, the parent update service node communicates through the 

20 child's update web service 202. 

In an actual embodiment of the present invention, the common set of Web 
services provided by the update web service 202, generally referred to as the web services 
interface, includes tlie following calls: GetServerAuthConfig for obtaining authentication 
configuration information from a parent update service node; GetConfigData and 

25 GetServerConfigData for obtaining parent update server node configuration information 
and properties; GetServerCookie for obtaining an authorization token from a parent 
update service node; GetRevisionldList for obtaining an update list from a parent update 
service node; GetUpdateData for obtaining update metadata and update payloads from a 
parent update service node; and ReportEvents for reporting the update activity that 

30 occurred on an update service node to its parent update service node. 

The client update module 204 handles communications between a client computer 
and the update service node 200 in regard to updates and update information stored on the 
update service node. The update-related communications include, but are not limited to, 
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distributing updates in response to client requests and providing a list of available 
software products and associated updates for the client computer. The client update 
module 204 is also responsible for determining whether a cUent computer is authorized to 
obtain a particular update according to associated distribution rules, and responds to a 
cUent computer with the update-related information that the chent computer is authorized 
to access. 

The child update module 206 handles update-related communications between a 
parent update service node and its child update service nodes. The update-related 
commimications include, but are not limited to, identifying Usts of software products and 
associated updates available to a child update service node, as well as responding to 
update requests from a child update service node. The downstream update module 206 is 
responsible for determining whether a child update service node is authorized to obtain a 
particular update according to associated distribution rules, and responds to a child update 
service node with the update-related information that the child update service node is 
authorized to access. 

The reporting module 208 generates update-related reports, such as which groups 
have or have not received a particular update, which client computers have or have not 
downloaded/installed an update, what updates are available on the update service node, 
and the like. These reports may be used internally, such as by an administrator, and also 
submitted to the parent update service node, via the parent's update service interface 202. 
As described above, it is often necessary for corporations to determine which client 
computers have a particular update installed, such as for billing pxirposes or for 
maintenance purposes. Information/reports generated by the reporting module 208 may 
be the basis of these reports. 

The authentication/authorization module 210 is responsible for authenticating, i.e., 
determining the identity of, a particular client computer or child update service node, and 
determining whether a client computer or child update service node is authorized to 
access available updates at the update service node 200. To those client computers and 
child update service nodes that are authenticated and authorized to access updates on an 
update service node, the authentication/authorization module 210 issues an authorization 
token that must be used in conjunction with obtaining updates. The issuance and use of 
an authorization token is described in greater detail below in regard to FIGURES 4A and 
4B. 
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The administration API 212 represents the application interface through which 
control of the update service node 200 is exercised, and through wliich updates ultinxately 
are stored and distributed. When the update web service 202 receives various 
update-related requests from client computers and child update service nodes, these 
requests are ultimately broken into calls into the administration API 212, either directly or 
indirectly through the cUent update module 204 and the child update module 206. in 
conjunction with the administration user interface 218 or some other program installed on 
the update service node 200 suitably configured to use the administration API 21 2, an 
administrator ultimately controls all aspects of the update process for that update service 
node, as well as any child update service nodes and client computers. An actual 
embodiment of an administration API is attached as an appendix to this specification, and 
described in greater detail below in regard to FIGURES 9-XX. 

Through the administration user interface 218, administrators may configure and 
maintain an update service node 200, via the administration API 212. Thus, through the 
administration user interface 218, an administrator creates, modifies, and deletes groups, 
as well as associating rules for each group. Furthermore, using the administration user 
interface 218, an administrator estabUshes to which group a cUent computer or child 
update service node belongs. Through the adnunistration user interface 21 8, an 
administrator may also explicitly authorize the distribution of updates to chent computers 
or child update service nodes, configure the update service node 200 to periodically query 
its parent update service node for new updates, configure reporting parameters and view 
intemal reports, and the like. As mentioned above, while the administratioix user 
interface 218 permits an administrator to exercise control over aspects of the ixpdate 
service node 200, another application residing on the update service node 200, suitably 
adapted to operate with the administration API 212, may be used instead of the 
administration user interface 218. 

As mentioned above, according to one embodiment of the present invention, an 
update service node 200 includes both an update content store 214 and an mpdate 
information store 216. The update content store 214 stores the actual files representing 
the software updates, such as binaries and patch files. In contrast, the update information 
store 216 stores mformation and metadata corresponding to the updates available on the 
update service node 200, including the update files stored in the update content store 214. 
According to one embodiment, the update content store 214 and the update information 
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Store 216 are both relational databases. While the exemplary xipdate service node 200 is 
shown as having two data stores, the present invention should not be so limited. In an 
alternative embodiment, both the update content store 214 and the update information 
store 216 may be combined in a single information store. 

In accordance with aspects of the present invention, a software update may be 
presented as being "available" on an update service node 200 to client computers and 
child update service nodes even though the update is not stored physically in the update 
content store 214. More particularly, rather than immediately downloading and storing 
the actual update files on an update service node 200, a link referencing the update files 
on the parent update service node or elsewhere, may instead be stored on the update 
service node. Thus, if a chent computer requests the update, or a child update service 
node requests the actual update, the update is then brought down firom the parent update 
service node and stored in the update content store 214, in preparation for delivering it to 
the client computer or child update service node. Those skilled in the art will recognize 
this type of update access is referred to as just-in-time downloading. In this manner, an 
"available" update, need not be distributed over the various network channels until it is 
actually requested. According to aspects of the present invention, an administrator of an 
update service node 200 may selectively determine whether to obtain software updates in 
a just-in-time manner. 

While the above description of FIGURE 2 illustrates various components of an 
exemplary update service module 200, it should be appreciated that other components of 
an update service module may also exist. Furthermore, the above described components 
should be understood to be logical components, not necessarily actual components. In an 
actual implementation, the above identified components may be combined together 
and/or with other components according to implementation determinations. Additionally, 
it should be appreciated that while an update service node 200 may be viewed as a server 
computer on a network, in an actual implementation, an update service node may be 
implemented on any number of types of computing devices. For example, each update 
service node 200 may be implemented and/or installed on a single stand-alone computer 
system or, alternatively, on a distributed computing system comprising multiple 
computing dcAdces. 

FIGURE 3 is a block diagram illustrating exemplary logical components of a root 
update service node 300, such as the root update service node 102 illustrated in 
' -13- 
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FIGURE 1, formed in accordance with aspects of the present invention. Similar to the 
logical components of an update service node 200 (FIGURE 2), a root update service 
node 300 includes an update web service 202, a child update module 206, and an 
authentication/authorization module 210. Additionally, an exemplary root update service 
5 node 300 also includes an administration API 212, an update content store 214, and an 
update information store 216. Optionally, the root update service node 300 may also 
include a client update module 204, a reporting module 208, and an administration user 
interface 218. 

The client update module 204 is an optional component for a root update service 

10 node 300 depending on whether the root update service node provides software updates 
directly to client computers. For example, with reference to FIGURE 1, root update 
service node 102 would include the optional client update module 204 as the root update 
service node that directly services client computer 1 12. However, if a root update service 
node 300 were not to directly service cUent computers, the client update module 204 

1 5 could be omitted. 

The reporting module 208 is optional for a root update service node 300 because a 
root update service node has no parent update service node to whom update reports are 
provided. However, to the extent that update reports are desirable to the root update 
service node's administrator, the reporting module 208 may be optionally included. 

20 In addition to comprising the logical components included in an update service 

node 200 (FIGURE 2), the root update service node 300 also includes a software provider 
interface 302. The software provider interface 302 provides the communication interface 
by which a software provider 110 (FIGURE 1) submits software updates directly to the 
root update service node 300, and indirectly to the exemplary update distribution 

25 system 100. 

Similar to the update service node 200 of FIGURE 2, tlie above description of 
FIGURES illustrates various components of an exemplary root update service 
module 300. However, it should be appreciated that other components of a root update 
service module may also exist. Furthermore, the above described components should be 
30 understood to be logical components, not necessarily actual components. In an actual 
implementation, the above identified components may be combined together and/or with 
other components according to implementation determinations. Additionally, it should be 
appreciated that while a root update service node 200 may be viewed as a server 
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computer on a network, in an actual implementation, an update service node may be 
implemented on any number of computing devices. For example, the root update service 
node 300 may be implemented and/or installed on a single stand-alone computer system 
or, alternatively, on a distributed computing system comprising multiple computing 
5 devices. 

In order to better understand how an update is disixibuted from the root update 
service node throughout an update distribution systena 100, an illustration of an 
exemplary exchange between a parent update service node and a child update service 
node is warranted. FIGURE 4 is a block diagram illustratinig an exemplary exchange 400 
10 between a parent update service node 402 and a child update service node 404 in 
propagating a software update from the parent update service node to the child update 
service node, in accordance with aspects of the present iu'vention. As can be seen, the 
exemplary diagram 400 is divided in half, the left half of which corresponds to actions 
and events of the parent update service node 402, and the right half corresponding to 
15 actions and events of the child update service node 404. 

For purposes of discussion with regard to FIGURE 4, it should be further 
understood that the parent update service node 402 may or may not be the root update 
service node in the update distribution system 100. Additionally, for piuposes of this 
discussion, it is assumed that the parent update service node 402 has been configured by 
20 an administrator such that the child update service node 404 may not receive software 
updates unless explicitly authorized to do so by the administrator. 

As shown in the exemplary exchange 400, beginming at event 406, the parent 
update service node 402 receives a software update from a- software provider 110, either 
directly, if the parent update service node is the root update service node 102, or 
25 indirectly through the update distribution system 100. At some point after the parent 
update service node 402 receives the software update from the software provider 110, the 
child update service node 404 begins a process for obtaining software updates from the 
parent update service node. 

According to one embodiment, a child update service node 404 can be configured 
30 to automatically obtain the software updates available fiom a parent update service 
node 202 on a periodic basis. More particularly, an admindstrator, via the administration 
user interface 218, may selectively configure the child update service node 404 to 
automatically obtain the latest software updates available on the parent update service 
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node 402 on a periodic basis. As one example, an administrator may configure the child 
update service node 404 to obtain the latest software updates from its parent update 
service node 402 on a daily and/or hourly basis, as well as specify the time-of-day that 
the automatic update process is to commence. Other periodic schedules and criteria may 
also be utilized. Similarly, an administrator may manually initiate the update process 
through the administration user interface 218. 

To begin the updating process, at event 408 the child update service node 404 
authenticates and authorizes itself with the parent update service node 402. 
Authenticating and authorizing with the parent update service node 402 provides an 
element of control over the distribution of software updates, Umiting iq)date distribution 
to authorized update service nodes. Authenticating and authorizing techniques are well 
known in the art, any number of which may be employed to authenticate and authorize a 
child update service node 404 with the parent update service node 402, The present 
invention is not restricted to any one technique. 

After properly authenticating and authorizing with the parent update service 
node 402, at event 410 the parent update service node 402 returns an authorization token 
to the child update service node 404. According to one embodiment, an authorization 
token is a time sensitive token providing the child update service node 404 authorization 
to conduct further update activities with the parent update service node for a limited 
amoxmt of time. Thus, if the child update service node 404 is not properly authenticated 
and authorized with the parent update service node, no authorization token is retumed and 
the child update service node is unable to perform any other update-related activities 
except authentication and authorization. Similarly, after the update token has expired, the 
child update service node 404 is unable to perform any fiirther update-related activities 
with the parent update service node 402 except reauthentication and reauthorization. 

After receiving the authorization token, at event 412 the child update service 
node 404 submits a request to the parent update service node for a product update catalog 
along with the authorization token. A product update catalog represents a listing, or table 
of contents, of software products for which the parent update service node 402 distributes 
software updates. 

According to aspects of the present invention, a child update service node 404 is 
not required to propagate all software updates available on its parent update service 
node 402. For example, with reference to the exemplary update distribution system of 
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FIGURE 1, the corporate update service node 104 may have site licenses to only a 
fraction of software products available on the root update service node 102. Accordingly, 
it would be unnecessary for the corporate update service node 1 04 to obtain all software 
updates available at the root update service node 102, as most would never be used. 
5 Accordingly, an administrator on an update service node may s&lectively establish which 
software product updates will be available on the update service node. 

According to one aspect of the present invention, the update product catalog, 
obtained from a parent update service node 402, identifies all so£=itware products for which 
updates are available, whether or not tiie child update service n.ode 404 is configured to 
10 distribute updates for each product. However, according to an alternative aspect of the 
present invention, the update product catalog, obtained from a parent update service 
node 402, identifies only those software products for which the? requesting child update 
service node is configured to distribute updates. For example, limiting which software 
products are listed in the product update catalog may be deteamined according to the 
15 group or groups to which the child update service node 404 belongs. 

At event 414, the parent update service node 402 returns a product update catalog 
to the child update service node 404. At event 416, the child update service node 404 
selects those products from the product update catalog for whioh the latest updates are 
currently desired. It should be noted that even though the product update catalog may list 
20 only those software products that the child update service node -404 distributes, the child 
update service node may be configured to obtain updates for different software products 
at different times or on different periodic schedules. 

At event 418, the child update service node 40-4 submits an update 
synchronization request, along with the authorization token, identifying the selected 
25 products for whose updates the child update service node is currently seeking. Included 
in the synchronization request is information identifying the latest update available for a 
product on the child update service node 404. Information ider:itifying the latest update 
for a product is hereafter referred to as an "update anchor." Update anchors for each 
software product are typically stored in the update infomiation store 216 (FIGURE 2). In 
30 one embodiment, an update anchor includes a revision number axid a date associated with 
the revision number. 

In response to the update synchronization request, at eve^nt 420 the parent update 
service node 402 determines which, if any, new updates are available for the child update 
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service node 404. As mentioned above, this detemination is based on the specific rules 
associated with particular software updates and the group or groups of which a child 
update service node 404 is a member, as well as the update anchor. For this example, as 
previously mentioned, the previously received software update was explicitly not 
authorized for the child update service node 404. Therefore, the software update received 
at event 406 is not determined to be "available" to the child update service node 404. 
Accordingly, at event 422 an update list is returned to the child update service node 404 
without identifying the software update received at event 406. According to aspects of 
the present invention, the update list identifies all of the updates "available" on the parent 
update service node 402 according to the synchronization request. In one embodiment, 
the update list identifies each "available" update information by a unique identifier 
associated with an update. 

At event 424, because the update list is empty, i.e., no updates are currently 
"available" on the parent update service node 402, the update process of the child update 
service node 404 simply delays, or sleeps, for a predetermined amount of time. 
According to the current example, during this delay period, at event 426, an administrator 
at the parent update service node 402 authorizes the software update, received at 
event 406, to be distributed to the child update service node 404. 

At event 428 (FIGURE 4B), the child update service node 404 again begins the 
automatic update process by authenticating and authorizing itself with the parent update 
service node 402. In response, at event 430, the parent update service node 402 returns 
. an authorization token to the child update service node 404. 

At event 432, the child update service node 404 submits a request, along with the 
authorization token, to the parent update service node 402 for a product update catalog. 
At event 434, the parent update service node 402 returns the product update catalog to the 
child update service node 404. At event 436, the child update service node 404 selects 
the products for the update catalog for which updates are desired. At event 438, the child 
update service node 404 submits the update synchronization request identifying those 
selected products with the authorization token. 

Because the child update service node 404 has been authorized to obtain the 
software update previously received at event 406, at event 440 the parent update service 
node 402 determines that the software update is "available" for the child update service 
node aad includes corresponding update information in the update list. Thereafter, at 
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event 442, the parent update service node 402 returns the update list, now identifying the 
software update received at event 406, to the child update service node 404. 

With an update list identifying an "available" update on the parent update service 
node 402, the child update service node 404 now has the information necessary to obtain 
5 the software update. According to one embodiment of the present invention, a child 
update service node 404 obtains the software update from the parent update service 
node 402 in two parts: obtaining update metadata, and obtaining the update content or 
file, hereafter referred to as the update payload. According to additional aspects of the 
present invention, the update metadata describes pertinent aspects of the software update, 
10 including, but not limited to: an update identifier that uniquely identifies the update, 
revision number information associated with the software update, whether the software 
update should be considered a priority, language specific information, relationships to 
other software updates, location of the update payload for downloading purposes, 
installation handler routines, and the like. 

Some of the reasons that it is often beneficial to download the entire software 
update in two parts, i.e., the update metadata and the update payload, is that the update 
payload is often substantially larger than the update metadata, and the update payload is 
not always immediately needed, i.e., needed for mstallation on a client computer, if it is 
ever needed. Thus, according to one embodiment of the present invention, the update 
payload is downloaded separately from the update metadata, and only when needed. 
Those skilled in the art will recognize this downloading technique as lazy downloading, 
or altematively as just-in-time downloading. According to aspects of the present 
invention, an administrator may configure an update service node to obtain the update 
payload in a just-in-time fashion, or immediately upon obtaining the update metadata. 
Furthemaore, in an alternative embodiment, both update metadata and the update payload 
may be downloaded jointly. 

As shown in FIGURE 4B, with an update identified in the update hst, at 
event 444, the child update service node 404 requests the update metadata for the 
"available" software update according to its unique identifier in the update list. As with 
most other communication exchanges with the parent update service node 402, the update 
request is submitted with the authorization token. It should be noted that while in the 
illustrated example, all update metadata is dovraloaded in one access, according to 
altemative aspects of the present invention (not shown), the update metadata may be 
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downloaded in more than one access. For example, in a first access, only elements of the 
update metadata to are necessary to determine whether a software update is applicable 
and/or desirable is first downloaded, such as applicability rules and dependencies upon 
other software updates. Then, after it is determined that an update is applicable and/or 
5 desirable, the remainder of the update metadata may be obtained. In response, at 
event 446 the parent update service node 402 returns the update metadata for the software 
update child update service node 404, which in turn stores the update metadata into the 
update information store 216. 

hi one embodiment, the update metadata includes, but is not Umited to: a unique 

10 identifier associated with a particular update; a description of the update, such as size oF 
the update, problems addressed by the update, revision/anchor information, and the like; 
update applicability rules, such as whether the update requires a previous update to be 
installed, whether the update must be installed separately, whether the update supersedes, 
other available updates, and the like; end user license agreement data; and URI^ 

15 information for locating and/or accessing the update payload if it is not stored on th^ 
parent update service node 402. 

Optionally, at event 448, the child update service node 404 submits a request to 
download the update payload firom the parent update service node 402. In response, at 
event 450, the parent update service node 402 returns the update payload to the child 

20 update service node 404, which in tum stores it in the update content store 214. 

Because update activity has now occurred on the child update service node 404, a^t 
event 452, the child update service node generates and submits an update report to the 
parent update service node 402 outlining the update activities that have just recently- 
occurred. Thereafter, the child update service node 404 again delays until the next time 

25 that the update process is scheduled to run (not shown). 

Those skilled in the ait will appreciate that the above described events are fojc 
illustration purposes, and reflect one particular exemplary set of events and 
circumstances. Clearly, other events may also occur according to specific details and 
circumstances which will cause some variation to the above described events-. 

30 Additionally, it should be understood that while the child update service node 404 is 
obtaining ttie latest "available" software updates firom the parent update service node 402., 
the child update service node may simultaneously be processing update requests from its 
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child update service nodes. Accordingly, the above sequence of events should be viewed 

as illustrative only, and not limiting upon the present invention. 

FIGURE 5 is a flow diagram illustrating an exemplary routine 500 executed on a 

child update service node, such as the corporate update service node 104 of FIGURE 1, 
for periodicaUy obtaining updates from its parent update service node. Beginning at 
block 502, the child update service node obtains a synchronized update Ust of "available" 
updates from the parent update service node. Obtaining a synchronized update list of 
"available" updates from the parent update service node is described below with regard to 
HGUREd. 



FIGURE 6 is a flow diagram of an exemplary subroutine 600, suitable for use in 
the exemplary routine 500 of FIGURE 5, for obtaining a synchronized update list of 
"available" updates from a parent update service node. Beginning at block 602, as 
previously discussed with regard to FIGURES 4A and 4B, the child update service node 
authenticates and authorizes itself with the parent update service node and, in response to 
1 5 proper authentication and authorization, receives an authorization token. At block 604, in 
conjunction with the authorization token, the child update service node estabUshes 
communication parameters with the parent update service node. Establishing 
communication parameters permits the parent and child update service nodes to properly 
establish a common basis that both the parent and child understand. The communication 
parameters include, but are not limited to: communication update protocols or versions; 
product groupings; and the like. 

After having established communication parameters with the parent update 
service node, at block 606, the child update service node obtains a product update catalog 
describing software products for which the parent update service node 
provides/distributes updates. At block 608, the child update service node selects those 
software product updates for which updates are currently sought. At block 610, the child 
update service node submits an update synchronization request to the parent update 
service node, including both the authorization token and an "anchor" associated with the 
selected software products identifying the current revision and updates ahready on the 
3 0 child update service node. 

In response to the update synchronization request, at block 612, the child update 
service node obtains an update list from the parent update service node, synchronized 
according to the software updates "available" on the parent update service node according 
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to what is currently stored on the child update service node. As mentioned above, the 
update list identifies, by a unique identifier, those software updates on the parent update 
service node that are "available" to the child update service node. Thereafter, the 
exemplary subroutine 600 terminates. 
5 With reference again to FIGURE 5, after having obtained a synchronized update 

list from the parent update service node, at decision block 504, a determination is made as 
to whether any software updates are currently "available" for downloading from the 
parent update service node. This determination is made according to whether there are 
any update identifiers listed in the synchronized update list If no software updates are 
10 currently "available" for downloading, the exemplary routine 500 proceeds to delay 
block 510, where the exemplary routine delays/sleeps until the next update period occurs. 
Alternatively, if there are updates "available" for downloading from the parent update 
service node, at block 506, the child update service node obtains the updates from the 
parent update service node. Obtaining "available" updates from the parent update service 
1 5 node is described below with regard to FIGURE 7. 

FIGURE 7 is a flow diagram of an exemplary subroutine 700, suitable for use in 
the exemplary routine 500 of FIGURE 5, for obtaining "available" software updates from 
a parent update service node. Beginning at block 702, a first update identifier in the 
update list is selected. At block 704, the child update service node obtains the update 
metadata coiresponding to the selected update identifier from the paient update service 
node and stores it in the update information store 216. 

According to one embodiment, at block 706, the child update service node obtains 
the update payload corresponding to the selected update identifier from the parent update 
service node, and stores the update payload in the update content store 212. Optionally, 
the update content need not be immediately downloaded to the child update service node. 
As previously mentioned, a child update service node may be selectively configured to 
download updates from a parent update service node in a just-in-time fashion. According 
to this optional treatment, as illustrated in FIGURE 7, rather than proceeding from 
block 704 to block 706, the exemplary subroutine 700 optionally proceeds from 
block 704 to decision block 708. 

At decision block 708, after having obtained the update metadata for the selected 
update identifier, and optionally the update payload, a determination is made as to 
whether there are any additional update identifiers in the update list. If there are 
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additional update identifiers, at block 710, the next update identifier in the update list is 
selected, and the subroutine 700 returns to block 704 for additional processing. The 
routine 700 continues xmtil, at decision block 708, it is detemained that there are no more 
update identifiers in the update Ust, whereupon the exemplary subroutine 700 terminates. 

Returning again to FIGURE 5, after having obtained the "available^' updates firom 
the parent update service node, at block 508, the child update service node reports the 
update activities to the parent update service node. Thereafter, at delay block 510, the 
exemplary routine 500 delays/sleeps for a predetermined amount of time until the next 
update period, and then proceeds to block 502 to repeat the above-identified update 
procedures. 

As illustrated in FIGURE 5, at decision block 504, even when no updates are 
"available" on a parent update service node, a child update service node may be 
optionally configured to report its update activities to the parent update service node. 
According to this alternative configuration, when there are no updates available, the 
exemplary routine 500 may proceed to block 508 to report the update activities. 

FIGURE 8 is a flow diagram of an exemplary routine 800, implemented on a 
parent update service node, for generating a synchronized update list identifying 
"available" updates in response to an update synchronization request fi-om a child update 
service node. Beginning at block 802, the parent update service node receives an update 
synchronization request firom a child update service node for an update list identifying 
"available" updates. At block 804, the first software product identified in the update 
synchronization request is selected. 

At decision block 806, a determination is made as to whether there are any 
available updates for the identified software product. This determination is made 
according to metadata for the software product stored in the update information store 216, 
according to the update anchor provided by the child update service node, and according 
to distribution rules associated with the group to which the child update service node 
belongs. According to this detemiination, if there are updates "available," at block 808, 
imique update identifiers associated with the "available" updates are written into an 
update list. After having written unique update identifiers for "available" updates into the 
update hst, at decision block 810, a determination is made as to whether there are any 
more additional software products identified in the update synchronization request. If 
there are additional update software products in the update synchronization request, at 
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block 814, the parent update service node selects the next software product identified in 
the update synchronization request, and returns to decision block 806 for determining 
whether there are "available" updates for the selected software product. Alternatively, if 
there are not more software products identified in the update synchronization request, at 
5 block 814, the update list is returned to the child update service node. Thereafter, the 
exemplary subroutine 800 terminates. 

As mentioned above, an update service node is administered through the 
administration API 212 via the administration user interface 218, or some other similarly 
equipped module. To better understand how the administration API 212 operates, 
10 FIGURE 9 is a pictorial diagram for illustrating how the administration API is utilized 
with regard to configuring an update service node to distribute software updates to client 
computers. 

As shown in FIGURE 9, an administrator uses the administration API to generate 
subscriptions 904 and groups 906. The update service node, during an update 
15 process 908, uses the updates 902 available to that update service node, as well as the 
subscriptions 904 and groups 906, to distribute the updates to client computers, such as 
client computers 912-922. 

As those skilled in the art will appreciate, an administrator generates a 
subscription to updates for a particular product or product family, as well as the class of 
update. For example, a product may be Microsoft Corporation's Internet Explorer 
product, and a subscription would indicate this product in waiting for available updates. 
Sunilarly, a product family would typically indicate a number of products, such as 
Microsoft Corporation's Office as a product family, that includes numerous identifiable 
products. Subscriptions also typically identify the type of update that is approved for 
download onto client computers. For example, the type of an update may be critical, 
severe, general, etc. 

According to one embodiment of the present invention, cUent computers are 
organized into groups, and subscriptions and updates are applied to groups. In an actual 
embodiment, each client computer belongs to two groups: an all computers group, and 
one other group. According to this actual embodiment, the update service node has 
defined the all computers group and one other, an unassigned computers group. Through 
the administration API 212, the administrator is fi-ee to defme any number of other 
groups, and assigned client computers to a group. Failing to assign a client computer to a 
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group leaves the client computer in the unassigned group. In short, according to this 
embodiment, a client computer belongs to the all computers group and one other. Groups 
may include any number of clients computers. Groups of client computers, for applying 
software updates, are illustrated in FIGURE 9 as boxes 910, 924, and 926. 
5 According to an actual embodiment, the administration API 212 is the interface 

through which Microsoft Corporation's Windows Software Update Services is configured 
and administered. In this embodiment, the administration API 212 is generally 
implemented by or accessible through the interface object lupdateServer. The description 
of an actual embodiment of the lUpdateServer interface object is Usted at the end of this 

10 section as Table 1. This lUpdateServer interface object is part of the administration API 
document included as part of the U.S. Provisional AppUcation No. 60/553,042, filed 
March 12, 2004, which is incorporated herein by reference. However, various interface 
calls identified in Table 1 are generally described below in regard to FIGURE 10. 

FIGURE 10 is a block diagram illustrating certain administration API calls for 

15 administering the distribution of soflM^are updates on an update service node. With 
access to an lUpdateServer 1002 object, a caller can make interface calls for obtaining 
update service node configuration information 1004, current subscription 
information 1006, current approval rules 1008, update service node status 
information 1010, get updates 1012, get client computers 1014, and get groups 1016. 

20 The configuration information interface call 1004 provides access to configurable 

(and readable) values of the update service node, including, but not limited to, available 
languages, who is the parent update service node and location for that parent update 
service node, proxy servers and addresses, the mode in which the update service node 
synchronizes updates with its parent update service node, and the like. In an actual 

25 embodiment, as described in the attached appendix, the configuration information 
interface call 1004 is the "GetConfiguration" mterface call on the lUpdateServer object, 
which returns an instance of an IConfiguration mterface object for the update service 
node. The IConfiguration interface object is described in greater detail in the 
incorporated API of the provisional application. 

30 The subscription information interface call 1006 provides access to subscription 

information, uicluding, but not limited to, the status of the most recent subscription 
efforts, when the next subscription effort (e.g., downloading a particular update to a client 
computer) will be completed, the firequency of the subscription synchronization, and the 
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like. In an actual embodiment, there are at least two different interface calls to obtain 
subscription information. The "GetSubscrition" interface call on the lUpdateServer 
object retums a ISubscription interface object corresponding to a specific subscription on 
the update service node, and the "GetSubscriptions" interface call returns a collection of 
5 ISubscription interface objects. Additionally, a subscription is created using the 
"CreateSubscription" interface call, which creates an empty subscription on the update 
service node. Details of the ISubscription interface object are described in the 
incorporated API of the provisional application. 

The update service node status interface call 1010 provides access to update 

10 service node status including, but not limited to, the currently deployed updates, available 
updates, and the like. In an actual embodiment, the "GetUpdatesSummary" interface call 
retums a summary collection object describing overall update summary information for 
the update service node. Details regarding this interface call are described in the 
incorporated API of the provisional application. 

15 The get updates interface call 1012 provides access to information regarding 

available software updates. More particularly, the interface call provides access to all 
software updates available in the system. In an actual embodiment, there are several 
interface calls to obtain update information. The "GetUpdate" interface call retums an 
lUpdate object that provides information regarding a specific update on the system. 

20 Additionally, the "GetUpdates" interface call retums a collection of lUpdates objects 
available to the system. Additional details regarding these interface calls is provided in 
the incorporated API of the provisional application. 

The get computers interface call 1014 provides access to the cUent computers 
associated with the update service node. In an actual embodiment, there are at least two 

25 interface calls to access information regarding the various client computers, including, 
but not limited to, a "GetComputer" interface call that retums an IComputer object 
corresponding to a client computer identified in the interface call, and a "GetComputers" 
interface call that retums a collection of IComputer objects, the collection includes all 
chent computers associated with the update service node. As above, additional details 

30 regarding this interface calls on the lUpdateSever object are described in the incorporated 
API of the provisional application. 

The get groups interface call 1016 provides access to the groups defined on the 
update service node. As mentioned above, in an actual embodiment, each cUent 
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computer belongs to the all-computers group and one other group. If a client computer is 
not assigned to a group, that cUent computer defaults to the unassigned group. In at least 
this actual embodiment, a number of interface caUs are available including, but not 
limited to, a "GetTargetGroup" interface call that returns an ITargetGroup object 
5 corresponding to a group identifier passed to the interface call, and a "GetTargetGroups" 
interface call that returns a collection of ITargetGroup objects corresponding to all groups 
defined on the update service node. 

Those skilled in the art will appreciate that while some of the interface calls have 
been described, they are not an exhaustive set of interface calls. Indeed, as illustrated in 
10 the attached appendix, an actual embodiment of an administration API includes numerous 
interface calls, the majority of which have not been specifically described. 

With regard to the following table, Table 1, the abbreviation WUS is an acronym 
for Windows Update Server. 



Table 1 



lUpdateServer 




Use this interfece to access Update Server components. 




The lUpdateServer interface is derived from the System.Object class. 


Public Methods 




The lUpdateServer interface has the following public methods. 


Method 


Description 




Cancels updates that are currently being 


CancelAllDownloadsQ 


downloaded to the WUS server. 




Creates a target group that you use to target client 


CreateComputerTargetGroup(String) 


computers for updates. 




Determines if the specified Object is equal to tiie 


£quals(Object) 


current Object. 


GetComponentsWithErrorsO 


Retrieves a list of server components that are 
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currently in an error state. 


GetCoinputersNotContactedSinceCount(DateTiine) 


Status to the WUS server since the specified time. 


GetConiputerTarget(String) 


Retrieves the specified client computer. 


GetCoinputerTargetGroup(Guid) 


Retrieves the specified target group. 


GetComputerTargetGroupsQ 


jxeineves a cojiecuon oi aii inc loigci gruupo uii 
the WUS server. 


GetComputerXargetsO 


jxeuieves a couecuon oi aii ciiem couipuicid uiai 
are known to the WUS server. 


GetConfigurationQ 


jxeijieves an iupQaicDcrvcrv./UixiigLixauuu uuii yuu 
use to configure the WUS server. 


GetContentDownloadFrogressQ 


JVCIXlCVCo lite L/XVKiC^a Ui. <tll upUAica uiai cii-t. 

currently downloading. 


GetDatabaseConfigurationO 


T? *»+T-i f^Tm a an 1 \ lit^VidCAf^rttifioniTflfinTi f'nflt' vmi 11*5S 
JVcLilvVCo cin lX</ctlUUadCV.^Ull-LigUIall(Ji.i tllal yvru 

to determine the database configuiation. 


GetDo>vnstreainServer(Stnng) 


ivexrieves an mieriace lo uic spcciiicu uuvvnaucaiii 
WUS server. 


GetDownstreamServersO 


Retrieves a collection of downstream WUS 
servers that are registered with this WUS server. 

Serves as a hash function for a particular type. 


GetHashCodeO 


GelHashCode is suitable for use in hashing 
algorithms and data structures like a hash table. 

Retrieves the approval rule that is used to 


GetlnstallApprovalRuIeQ 


automatically download and install updates on 
target computers. 
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GetRootUpdateCategoriesO 
GetScanApprovalRuleO 

GetStatusQ 

GetSubscriptionO 
GetSubscriptionEvent(Guid) 

GetSynchronizationInfo(Guid) 
GetTypeO 

GetUpdate(UpdateReyisionId) 
GetUpdateApp r o val(Guid) 

GetUpdateCategoriesQ 
GetUpdateCategorics(DatcTime, DateTime) 

GetUpdateCategory(Guid) 
GetUpdateClassincation(Guid) 



Retrieves a collection of the top-level categories 
on the WUS server. 

Retrieves the approval rule used to automatically 
scan the target computers to determine if the 
update is applicable. 

Retrieves statistics that summarize the current 
state of the WUS server, updates, and the client 
computers. 

Retrieves a subscription instance that you use to 
manage the synchronization process. 

Retrieves a subscription event that identifies 
changes to the subscription. 

Retrieves information that is related to a specific 
synchronization process. 

Retrieves the Type of tiie current instance. 
Retrieves the specified update. 
Retrieves the specified approval. 

Retrieves the list of all update categories that are 
known to the WUS server. 

Retrieves die update categories that were added 
within the specified date range. 

Retrieves the category of updates for the given 
identifier. 

Retrieves the requested update classification. 
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GetUpdateCIassificationsO 


Retrieves a collection of update classifications that 
are known to the WUS server. 


GetUpdateClassiiications(DateTime, DateTime) 


Retrieves the update classifications that were 
added within the specified date range. 


GetUpdflte£ventflistory(DateTime, DateTime) 


Retrieves all installation events for all clients for 
the specified date range. 


GetUpdate£ventmstory(DateTime, DateTime, 


Retrieves all installation events that were raised by 


IComputerTarget) 


the specified client for the specified date range. 


GetUpdateEventHi$tory(DateTime, DateTime, 


Retrieves all installation events that were raised by 


lUpdate) 


all clients for the specified update and date range. 


GetUpdateEventHlstory(DateTime, DateTime, 
lUpdate, WusEventSource, WusEventId[]) 


Retrieves events based on the specified criteria. 


GetUpdatesO 


Retrieves a collection of the latest revision of each 
update. 


GetUpdates(ApprovedStates, DateTime, DateTime, 

UpdateCategoryCoIlection, 

UpdateClassificationCollection) 


Retrieves a collection of updates based on &e 
specined cntena. 


LogMessage(LiOgLevel, String, params Object(]) 


Logs a message to the software distribution log 
me* 


RegisterComputer(String) 


Registers a client computer with the WUS server. 
Forces the synchronization of all update metadata 


ResetAndVerifyContentStateQ 


on the WUS server and verifies that all update 
files on the WUS server are valid. 


ResumeAllDownloadsQ 


Identifies the updates to download. 


SearchCoinputerTargets(Striiig) 


Retrieves a collection of target computers whose 
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ftill domain name contains the given string. 


SearchUpdates(String) 


Retrieves a collection of updates whose metadata 
contains the given string. 


ToStringO 

* 


Retrieves a String that represents the current 
Object. 


Public Properties 




The lUpdateServer interface lias the following public property. 


Property 


Description 


PreferredCulture 


Retrieves or sets the language code that you want the WUS server 
to use when returning strings. 



While various embodiments, including the preferred embodiment, of the invention 
have been illustrated and described, it w^ill be appreciated that various changes can be 
made therein without departing from the spirit and scope of the invention. 



\ 
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